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REMARKS / ARGUMENTS 

The present application includes pending claims 1-24, all of which have been 
rejected. The Applicant respectfully submits that the claims define patentable subject 
matter. 

Claims 1, 3-5, 7, 10-12, 14-16, 18, 23-24 are rejected under 35 U.S.C. § 103(a) 
as being unpatentable over US Patent Ns 7,136,381 ("Battle"), in view of US Patent Nq 
6,069,971 ("Kanno"). Claims 2, 6, 8-9, 13, 17, 19-22 stand rejected under 35 U.S.C. § 
103(a) as being unpatentable over Battle in view of Kanno, further in view of U.S. Patent 
No. 6,484,261 ("Wieget"). The Applicant respectfully traverses these rejections at least 
based on the following remarks. 



REJECTION UNDER 35 U.S.C. § 103 

In order for a prima facie case of obviousness to be established, the Manual of 

Patent Examining Procedure, Rev. 6, Sep. 2007 ("MPEP") states the following: 

The key to supporting any rejection under 35 U.S.C. 103 is the clear 
articulation of the reason(s) why the claimed invention would have been 
obvious. The Supreme Court in KSR International Co. v. Teleflex Inc., 82 
USPQ2d 1385, 1396 (2007) noted that the analysis supporting a rejection 
under 35 U.S.C. 103 should be made explicit. The Federal Circuit has 
stated that "rejections on obviousness cannot be sustained with mere 
conclusory statements; instead, there must be some articulated reasoning 
with some rational underpinning to support the legal conclusion of 
obviousness." 
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See the MPEP at § 2142, citing In re Kahn, 441 F.3d 977, 988, 78 USPQ2d 1329, 1336 

(Fed. Cir. 2006), and KSR International Co. v. Teleflex Inc., 82 USPQ2d at 1396 

(quoting Federal Circuit statement with approval). Further, MPEP § 2143.01 states that 

"the mere fact that references can be combined or modified does not render the 

resultant combination obvious unless the results would have been predictable to one of 

ordinary skill in the art" (citing KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385, 

1396 (2007)). Additionally, if a prima facie case of obviousness is not established, the 

Applicant is under no obligation to submit evidence of nonobviousness: 

The examiner bears the initial burden of factually supporting any prima 
facie conclusion of obviousness. If the examiner does not produce a 
prima facie case, the applicant is under no obligation to submit evidence 
of nonobviousness. 

See MPEP at §2142. 

I. The Proposed Combination of Battle and Kanno Does Not Render Claims 1, 
3-5, 7, 10-12, 14-16, 18, 23-24 Unpatentable 

The Applicant now turns to the rejection of claims 1 , 3-5, 7, 1 0-1 2, 1 4-1 6, 1 8, 23- 
24 as being unpatentable over Battle in view of Kanno. The Applicant notes that the 
proposed combination of Battle and Kanno forms the basis for all of the pending 
rejections. 

A. Rejection of Independent Claims 1 and 12 under 35 U.S.C. § 103(a) 
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With regard to the rejection of independent claim 1 under 35 U.S.C. § 103(a), the 
Applicant submits that the combination of Battle-Kanno does not disclose or suggest at 
least the limitation of "comparing said destination port bit map with a physical port 
security bit map to generate a bit map of allowed destination ports, wherein said 
physical port security bit map is generated based on information in said received frame 
of digital data," as recited by the Applicant in independent claim 1 . 

The Office Action states the following: 

Battle teaches: A method of providing physical port security in a digital 
communication system, comprising: 



comparing said destination port bit map with a physical port security bit 
map to generate a bit map of allowed destination ports, wherein said 
physical port security bit map [i.e., vanPORTBITMAP] is generated 
based on information in said received frame of digital data (see e.g. 
figure 6, element 'Does any port in vanPORTBITMAP belong to a trunk 
group in the trunk table', element 'Calculate the HASH using the DA [Le., 
destination address] and SA [Le., source near address] in the packet'; 
and column 6, lines 12-30, particular note 'RTAG 2 RTAG identifies the 
trunk selection criteria for this trunk group 0: based on DA [i.e., 
destination address] + SA [i.e., source address]', of Battle; 

However, Battle does not specifically mention a separate physical 
security bit map. Kanno teaches a pattern comparison inspection 
system wherein Kanno discloses generate two separate bit maps and 
the compare the two separate bit maps (see figure 9; and column 9, lines 
28-38 "of Referring to FIG. 9, design pattern data 108 is converted into a 
gray level bit map (i.e., a reference bit map) 31 by occupancy calculating 
portion 23 and gray level bit map generating portion 24. EB pattern data 
109 is also converted into a gray level bit map (i.e., an inspected bit map) 
32. Bit map comparing portion 27 makes a comparison between 
reference bit map 31 and inspected bit map 32 and calculates an 
absolute value of each pixel value difference to generate a comparison 
result 33. It can be seen that the pixel value differences within 
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comparison result 33 are all equal to or less than 0.50.", Kanno, 
emphasis added). 

See the Office Action at pages 2-3. In reference to the above "comparing" limitation, the 
Examiner has repeated verbatim his argument stated in page 3 of the 10/19/2007 Office 
Action. However, the Examiner is now also relying on Kanno to teach "a separate 
physical security bit map." The Applicant maintains that Battle does not disclose all 
claim limitations recited in Applicant's claim 1. In addition, Kanno does not teach "a 
separate physical security bit map" and does not overcome the deficiencies of Battle. 

A(1) Battle's Deficiencies 

Apparently, the Examiner is equating Battle's "var:PORTBITMAP" variable to 
Applicant's "physical port security bit map." The Applicant respectfully disagrees and 
points out that Battle's var:PORTBITMAP is in fact the destination port bit map, 
which is generated pursuant to Battle's FIG. 4, and var:PORTBITMAP is not a 
separate physical port security bit map. 

Referring to FIG. 4 of Battle, the Applicant points out that after the 
var:PORTBITMAP variable is initialized (top of flow chart), then the opcode is 
determined using the module header. Based on the determined opcode, a 
determination is made as to the type of packet and the corresponding 
var:PORTBITMAP variable is set. In other words, the destination port bit map is 
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determined, once the type of packet is determined based on the opcode in the header. 
See Battle at FIG. 4 and col. 7, lines 30-43. 

FIGS. 5 and 6 of Battle continue the logical flow of FIG. 4. For example, FIG. 5 
discloses modifications to the destination port bit map (varPORTBITMAP), based 
on whether or not the packet has been mirrored. FIG. 6 discloses modifications 
to the destination port bit map (var:PORTBITMAP), if the ingress port is a member 
of a trunk group. In this regard, FIG. 6 of Battle does not disclose or suggest 
generation of a separate physical port security bit map. In fact, as stated above, 
varPORTBITMAP is the destination port bit map and it was initialized and generated as 
described in reference to FIG. 4. In FIG. 6 of Battle, var:PORTBITMAP is now simply 
being modified based on whether or not the ingress port is a member of a trunk 
group. This modification step is clearly seen in the last action block (last rectangle) 
before the decision block in FIG. 6. Namely, all the trunk ports that belong to the trunk 
group are removed from varPORTBITMAP and then the trunk port corresponding to 
Trunk_Port_N umber is obtained and added back to the varPORTBITMAP. In 
summary, Battle does not disclose or suggest generation of a separate physical 
port security bit map, and comparing the destination port bit map to any physical 
security port bit map. In fact, even if we assume for the sake of argument that 
Battle discloses a separate physical port security bit map, the Examiner's 
argument is still deficient since Battle does not disclose any comparison of the 
destination port bit map and the physical port security bit map for purposes of 
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generating a third, separate, bit map, i.e.. a bit map of allowed destination ports. 
As explained above. Battle, at most, only discloses modifying of the existing 
destination port bitmap (var:PORTBITMAP) based on whether or not the ingress 
port is a member of a trunk group. Battle does not even disclose any 
modification of the destination port bitmap based on whether or not one or more 
of the destination ports are, in fact, allowed destination ports. 

Kanno does not overcome the above deficiencies of Battle. 
A(2) Kano's Deficiencies 

The Examiner is relying on Kano to teach a separate physical port security bit 
map. The Applicant respectfully disagrees and initially points out that Kano and Battle 
are in completely different areas of technology. While Battle relates to switching 
within a local area network (LAN), Kano relates to inspecting pattern data for an 
electron beam patterning used in manufacturing integrated circuits. 

The Examiner relies on FIG. 9 of Kano, which discloses comparing of gray level 
bit maps to generate a comparison result bit map. Referring to FIG. 9 of Kano, the 
Applicant points out that the gray level bit maps 31 and 32 are in fact comprised of pixel 
values. In addition, Kano calculates the comparison result 33 by calculating a 
difference of corresponding pixel values from tables 31 and 32, and then calculating the 
absolute value of the difference between the pixel values. See Kano at col. 9, II. 28-38. 
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In this regard, Kano only discloses arithmetic manipulations (calculating a 
difference and then an absolute value of the difference) involving pixel values. 
Kano does not disclose any processing with regard to a separate physical port 
security bit map. In fact Kano only relates to pixel value processing and 
manipulation, and does not relate to any physical port characteristics or 
processing or a bit map of such physical port characteristics. 

Therefore, the Applicant maintains that the combination of Battle-Kanno does not 
disclose or suggest at least the limitation of "comparing said destination port bit map 
with a physical port security bit map to generate a bit map of allowed destination ports, 
wherein said physical port security bit map is generated based on information in said 
received frame of digital data," as recited by the Applicant in independent claim 1 . 

Accordingly, independent claim 1 is allowable. Independent claim 12 is similar in 
many respects to the method disclosed in independent claim 1. Therefore, the 
Applicant submits that independent claim 12 is also allowable over the references cited 
in the Office Action at least for the reasons stated above with regard to claim 1 . 

B. Rejection of Dependent Claims 3-5, 7, 10-11, 14-16, 18, and 23-24 

Based on at least the foregoing, the Applicant believes the rejection of 
independent claims 1 and 12 under 35 U.S.C. § 103(a) has been overcome and request 
that the rejection be withdrawn. Additionally, claims 3-5, 7, 10-11, 14-16, 18, and 23-24 
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depend from independent claims 1 and 12, respectively, and are, consequently, also 
respectfully submitted to be allowable. 

Applicant also reserves the right to argue additional reasons beyond those set 
forth above to support the allowability of claims 1 , 3-5, 7, 1 0-1 2, 1 4-1 6, 1 8, and 23-24. 

II. The Proposed Combination of Battle, Kano and Wieget Does Not Render 
Claims 2, 6, 8-9, 13, 17, and 19-22 Unpatentable 

Based on at least the foregoing, the Applicant believes the rejection of 
independent claims 1 and 12 under 35 U.S.C. § 103(a) as being unpatentable over 
Battle in view of Kano has been overcome and request that the rejection be withdrawn. 
Additionally, since the additional cited reference (Wieget) does not overcome the 
deficiencies of Battle and Kano, claims 2, 6, 8-9, 13, 17, and 19-22 depend from 
independent claims 1 and 12, and are, consequently, also respectfully submitted to be 
allowable. 

Applicant also reserves the right to argue additional reasons beyond those set 
forth above to support the allowability of claims 2, 6, 8-9, 13, 17, and 1 9-22. 
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CONCLUSION 

Based on at least the foregoing, the Applicant believes that all claims 1-24 are in 
condition for allowance. If the Examiner disagrees, the Applicant respectfully requests a 
telephone interview, and requests that the Examiner telephone the undersigned 
Attorney at (312)775-8176. 

The Commissioner is hereby authorized to charge any additional fees or credit 
any overpayment to the deposit account of McAndrews, Held & Malloy, Ltd., Account No. 
13-0017. 

A Notice of Allowability is courteously solicited. 

Respectfully submitted, 



Date: 04-AUG-2008 /Qqnvan I. Beremski/ 

Ognyan Beremski, Esq. 
Registration No. 51,458 
Attorney for Applicant 



McAndrews, Held & Malloy, Ltd. 
500 West Madison Street, 34th Floor 
Chicago, Illinois 60661 
(312)775-8000 

/OIB 
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